Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Timeout settings in SqsTemplate #1250

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

joey
Copy link

@joey joey commented Oct 2, 2024

📢 Type of change

  • Bugfix
  • New feature
  • Enhancement
  • Refactoring

📜 Description

  • Timeouts in SqsTemplate were being set by calling Duration#getSecondsPart which is always a number between 0 and 59
  • Update to use Duration#getSeconds to get the full timeout specified, in seconds

💡 Motivation and Context

This supports using a visibility time and polling timeout that's greater than 60 seconds.

💚 How did you test it?

Updated one of the unit tests for SqsTemplate

📝 Checklist

  • I reviewed submitted code
  • I added tests to verify changes
  • I updated reference documentation to reflect the change
  • All tests passing
  • No breaking changes

🔮 Next steps

* Timeouts were being set by calling Duration#getSecondsPart whic is
  alwawys a number between 0 and 59
* Update to use Duration#getSeconds to get the full timeout specified,
  in seconds
@github-actions github-actions bot added the component: sqs SQS integration related issue label Oct 2, 2024
@maciejwalkowiak maciejwalkowiak added the type: bug Something isn't working label Oct 3, 2024
Copy link
Contributor

@maciejwalkowiak maciejwalkowiak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM but @tomazfernandes take a look in case there are any side effects i am not aware of

@tomazfernandes
Copy link
Contributor

Looks good! It might be worth it checking if ContainerOptions has the same problem though.

@joey
Copy link
Author

joey commented Oct 3, 2024

Looks good! It might be worth it checking if ContainerOptions has the same problem though.

I didn't fine any other uses of the to<Unit>Part methods, so I think this the only place where this style of bug is present.

@@ -616,6 +616,15 @@ private ReceiveMessageRequest doCreateReceiveMessageRequest(Duration pollTimeout
return builder.build();
}

// Convert a long value to an int. Values larger than Integer.MAX_VALUE are set to Integer.MAX_VALUE
private int toInt(long longValue) {
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't want to use Math.toIntExact() as it will throw if the long value is out of the range and I thought pinning to the max integer would be better behavior. If we think it's unlikely enough that someone would set a timeout that high (over 63 years), then I'm happy to switch to the built in.

I didn't bother pinning too small of negative values as I don't think anyone would intentionally set a negative timeout.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can go with 2 approaches.

  1. Yours by rounding to maximum integer there is, which is totally valid.

  2. Or follow AWS SDK approach where we would (validate) throw exception with stating that value is above limit.

I personally would maybe want to go with approach number 2 just to be aligned, but both approaches are totally valid.
But tbh we are now nitpicking since no one will probably want or will set timeout that big. So for me this is fine!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: sqs SQS integration related issue type: bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants